Оценка сложности, качества и коллектива проекта

Работа расширяется и как правило превышает отпущенное на неё времяПервый закон Паркинсона

Проект - делопроизводство с вовлечением человеческих, финансовых и материальных ресурсов и организованный с тем что-бы уложиться в рамки ресурсов и времени и достичь поставленные тестируемые требования

Управление проектом - действия по направленному приложению усилий с применением имеющихся знаний и ресурсов ради достижения поставленных чётких целей. Успешность проекта полностью зависит от организации. Может оцениваться вещественно и невещественно (общественное мнение и тп.)

---

Типы проектов

• низкотехнологичные, основанные на существующих стандартах (например ERP, CMS)

• технологичные, основывающиеся на практически готовых технологиях (дополнения существующих проектов)

• высокотехнологичные, практическое большинство написано специально для проекта (программы для военных, софт для мобильных аппаратов)

• super high-tech

Оценка успешности проекта

• по времени, расходам, качеству выполненной работы до завершения проекта
• влияние на краткосрочную прибыль клиента
• по полученному положению (преимуществу) в сравнении с конкурентами
• по личному отношению клиента к выполненной работе

Цикл жизни и опыт коллектива

Методы подхода к реализации проекта можно разделить на:

Проектоориентированные - как организована работа коллектива	Системоориентированные - какой проект в техническом плане
- Waterfall

• Sashimi waterfall

• Staged Delivery

• Controlled Iteration

• Spiral

• RUP

• XP

• Scrum

• Evolutionary Prototyping

• Code and Fix

• Agile|- PMBOK - описывает область знаний и прилегающие области необходимые при выполнении проекта. Включает стандарты, общие требования к знаниям

• MPMM -

• Prince2|

Жизненный цикл проекта определяет время начала, конца и промежуточные периоды. Эти периоды (итерации, фазы) в зависимости от выбранной методологии и проекта могут быть к примеру:

• Необходимость, планирование,создание, проверка, завершение
• Дизайн, программирование, тестирование, обучение, выпуск

В свою очередь вне зависимости от масштаба периода, вплоть до элементарной задачи сотрудника, можно выделить мировоззрение PDCA - планировании, действии, проверке и докладу.

Оценка сложности

Происходит по аналогии либо по анализу. По аналогии соответсвенно похожие задачи были некогда проделаны и общее время известно. По анализу просчитывается количество функций, требований, сложности и действий с умножением на некую среднюю величину. Существует также и метод оценки PERT, работающий по формуле:

Оценка (чел/час) = (оптимистичная + 4 * ожидаемая + пессимистичная) /6

Включает в себя время, ресурсы, риски, последовательность. На этом этапе происходит как правило и WBS - разбивка проекта на части для получения иерархичной структуры заданий и их последовательности. Декомпозиция происходит так, что имеется предел на минимальный размер задания, а также задания одного уровня иерархии максимально независимы друг от друга.

Оценка должна учитывать в контексте системы четыре аспекта:

1. Разрабатываемый продукт для клиента
2. Бумажную работу и проволочки внутри фирмы (т.н. издержки на организацию работы)
3. Услуги и работы которые необходимо будет делать после завершения проекта (поддержка, обучение и тп.)

Сортировка задач по времени наглядно видна в MS Project, но в общем там заметны элегантные очевидности - параллельность выполняемых задач (leads) разными людьми в одно и то же вермя и необходимость в запасном времени (lag). Кроме очевидных зависимостей (Конец-Начало) между задачами, теоретически ведь возможны и разные комбинации, когда задачи должны либо завериться одновременно, либо хотя бы немного начаться.

Тем кто захочет создать универсальный планировщих задач прийдётся много попотеть. Ведь недостаточно получить число человеко-часов, надо перевести это на календарь с учётом зависимостей и параллельности задач. В простом случае такую оценку можно получить пройдясь по "критическому пути" - наиболее длинной по времени последовательности взаимосвязанных задач.

Согласно E. Goldratt'у оценка буфера проекта должна составлять 50% от длины критического пути. Если при разработке появляется опоздание в размере более чем 15-20% от критического пути, и невозможно привлечь дополнительные ресурсы, то необходимо делать компромисс между качеством, масштабу работ или оплатой. Потеря ключевого работника может внести опоздание дополнительно в 4-9 недель.

Оценка качества

Качество это тестируемая характеристика выполненной работы, выражающаяся в отношении предоставляемый возможностей к изначальным требованиям. По качеству продукта клиент автоматически судит о брэнде товара или компании.

Основные стандарты качества:

• Six Sigma - статистический метод от Motorola

• ISO 10006 - Guidelines to quality in project management

• TQM

• CMM

Очень показательны и методы планирования качества. Например анализ расходов (Cost-benefit analysis) можно наблюдать в фильме "Fight Club", где расходы на отзыв автомобилей был бы больше чем бездействие с ежекратной уплатой пострадавшим в авариях по страховке. Анализ расходов на достижение качества (Cost of Quality) с другой стороны показывает сколько надо тратить на всевозможные проверки, тестирование, стандартизацию, исправления, гарантии до выхода продукта.

В таком разнообразном мире много всевозможных переменных и не только в физическом мире, но и в программном обеспечении. Поэтому существует понятие риска, его вероятности и критичности. Стратегии по улучшению качества включают не только минимизацию риска, но и их смягчение, чёрные сценарии. В инфосистемах это можно наблюдать всюду - в валидации форм, ошибках 404, резервном копировании хостинга, подсказках (tips), подтверждениях (are you sure?), транзакциях с финансовыми операциями и тп.

Качество напрямую связано с тестерами. А они в свою очередь знакомы с некоторыми темами:

• Диаграммы причин-следствий (Ishikawa)
• Оценка на основе статистической выборке
• Японской философии постоянного совершенствования Kaizen
• Benchmarking, т.е. проверка на скорость реальной системы
• Принципом Парето 80-20

Проблемы можно классифицировать не только по сложности (слышали про гейзен-баги?) но и по человеческим причинам возникновения:

• "Без батареек". Человек спешил или самоуверенно не читал чужой код или документацию
• Смесь третьего ПО. Технократизм программера или архитектора, по гордости или глупости решившего использовать технологии без понимания их совместной работы (см. CORBA, COM и тп.)
• "А давайте добавим". Слишком большие энтузиасты-управляющие или ленивые программисты часто любят предложить дополнительную работу, не видя общего графика и желая оставить приятное впечатление.
• Несинхронная архитектура. Как правило затрагивает огромные проекты, где аналитический отдел и программисты не успевают друг за другом, а архитектура меняется на ходу. Причина - отсутсвие нормального управления архитектурой
• Убивающая Демо-версия. Отдел маркетинга ставит большую важность на демонстрацию системы как зацепляющего клиентов объект, из-за чего комманда разработчиков постоянно занята развитием и поддержкой прототипа самой новой версии и не занимается реальными проектами.
• Неправильный цикл. Большая контора, но цикл разработки ПО выбран неправильно, отсюда - нестыковки в графике, неизвестное состояние проекта, завышенные расходы.
• Клиент всегда прав. Постоянные дополнения вносимые управляющим проектом от клиента. В результате - нестабильный дизайн и куча ошибок, незаконченность или взаимосвязанность. Возникает из-за несфокусированности на целевых аудиториях.
• "Кольцо всевластья". Для универсальности и увеличения продуктивности в фирме все проекты подстраиваются под одну гребёнку, в результате у мелких проектов появляются лишние задачи.
• Эффект Домино. Ключевого разработчика/дизайнера/аналитика временно переводят на другой проект "помочь", поскольку пока проект отлично успевает. В результате всё идёт ещё хуже - ключевой человек забывает и не имеет понятия о состоянии старого проекта, но и не втянулся в новый проект. Причина - растущая компания, слишком много работы, зависимость от ключевых фигур.
• Угодить всем. Управляющие вмешиваются в проект в обход управляющего проектом, возникают параллельные задачи, стресс, изменения в планах.

Общение в коллективе

В больших компаниях (более 20 человек) идёт активное разделение и иерархия коллектива на роли и группы. Роли согласно RUP - аналитики, разработчики, тестеры, управляющие и остальные. Но для эффективной работы, создаются группы скажем "CMS PHP team", ".NET gps project team" и тд.

Во главе такой группы технарей стаит управляющий группой (team leader), который координирует работу внутри группы и с управляющим проектами. У нас в компании походая схема и зачастую возникает вопрос - к кому и как обращаться если возникли вопросы по проекту или что-то не так. Трясти постоянно team-leader'а не лучшее решение, он сам не железный, а просто так за спиной подходить к дизайнерам "ребят, исправьте тут работы на пару часов только.." тоже не совсем правильно.

Вообще существует несколько схем организации такой работы и общения.

1. Функциональная схема предполагает что работа идёт тому, кто наиболее опытен в этой сфере. Проект переходит от одной комманды к другой. Сначала анализ, потом дизайн, потом программирование и тп. Такую систему также сложно поддерживать, расширять или кардинально менять. Общаться практически ни скем не надо.

2. Безструктурная схема - небольшая анархия. Разговаривать приходится когда попало и с кем угодно, порой по разным проектам одновременно. Из-за этого возникает низкая продуктивность, невозможность предсказать времена.

3. Уровневая схема. Комманда разработчиков организована по уровню опытности со смешанными ролями. Так что верхние слои отвечают за архитектуру в целом, а нижние за менее важные и более приземлённые части. Работники принадлежат одновременно нескольким группам.

Информационный канал можно тоже упорядочить по степени пропускаемости: Бумажное письмо (без диалога), email, аудио-запись (без диалога), видео (без диалога), телефон, видео конференция, диалог возле доски.

По эволюции комманды с проектом, можно составить следующие психологические ступени:

1. Создание комманды (Forming), определение целей проекта, ролей участников и задач
2. Выяснение границ компетентности (Storming), поиск единого стиля
3. Нормализация отношений (Norming), доверие и спокойная совместная работа
4. Производственные отношения (Performing), вмешательство управляющих минимально

Оценка безопасности

По ISO существует несколько характеристик действий работника с системой.

1. Identification: who are you?
2. Authentication: how do I know your identity is true?
3. Authorization: are you allowed to perform this transaction?
4. Integrity: is the data you sent the same as the data I received?
5. Confidentiality: are we sure that nobody read the data you sent me?
6. Auditing: record of all transactions so we can look for security problems after the fact
7. Non-repudiation: both sender and receiver can provide legal proof to a third party (e.g. judge) that the sender did send the message, and the receiver received the identical message
8. Privacy: addresses the access purpose and data owner choice

Это была статья с вольным переводом основных тем лекций по предмету управления IT-проектами в ТТУ ( IDU3390 - Infos?steemi projekti juhtimine). В заключение - небольшой клип о том что может произойти в офисе если не соблюдать технику стрессовой безопасности и оптимизма